eDocs Home > BEA AquaLogic Data Services Platform Documentation > Data Services Developer's Guide > Contents

Relationship Modelling

In large enterprises modeling is — or at least should be — an early task in developing a data services layer. By starting with a graphical representation of data resources it is easier to view data resources globally, leveraging existing information in interesting and useful ways. It is also easy to see opportunities for creating additional business logic in the form of logical services.

Model diagrams are quite flexible; they can be based on existing data services (and corresponding underlying data sources), planned data services, or a combination. You can also create and modify data services and data service XML types directly from the model.

Relationships can be surfaced through the Relationship Modeler in several ways:

• Automatically. By dragging two or more relational-based data services into a model diagram simultaneously. In such cases primary/foreign key relationships -- already available in the respective data service -- appear.
• Graphically. Through gestures you make in your model diagram or through the right-click menu*.*
• Programmatically. Through a data service Source editor.

Relationship functions allows data associated with one data service (such as Customer) to serve as a complex parameter for a related data service (such as Orders). Models can represent any combination of logical and physical data services.
A visual representation of a relationship between two data services can convey a considerable amount of information:

• Cardinality. Is the relationship one-to-zero (customers and promotional offers), one-to-one (customer and primary email), one-to-many (customers and orders), or many-to-many (customer orders and ordered items)?
• Direction. Arrows indicate possible navigation paths. Is there an originating entity associated with a subordinate entity (such as orders and order items) or is the relationship bidirectional (such as customers and orders)?
• Roles. A name matching the name of the adjacent data services navigation function (see below). Does the assigned relationship name capture the purpose of the navigation function it represents?

Many data service-related operations can be performed from the relationship modeler including:

• Modeling a high-level, visual view of data resources
• Viewing and adding to the relationships between data services
• Accessing or creating a data service
• Add operations to a data service
• Change the XML type (schema) associated with a data service
  
  

Navigation functions are visible as properties of each data service in the binary relationship. They can be fully inspected in the Source editor for each data service. Navigation functions also appear as mouse-over text over each endpoint of the relationship line.

By default, types shown in model diagrams are XML schema types, but you can change this to display native data source types in the case of physical data services.

For more information on data service modeling concepts see Modeling and a Service-Oriented Architecture in the ALDSP 2.5 Concepts Guide.